Selective Hydrationのメリットがわかりづらい
@takepepe: App Router や Server Components が非機能要件に効くことをステークホルダーに説明できないと「採算あわないから今は pages で」にいつまでも停滞するので、そこの解像度をあげるのが急ぎという話。 @sadnessOjisan: @yuta0801_ なんかそれ、CDNでSSR結果返すのと何が違うんだという気持ちになるんですよね。それは全体hydrationとpartial hydration の違いになると思うんですけど、partial hydrationってそんなクリティカルな嬉しさってあるのかというのが個人的な感想です。少しでもパフォが良い方が良いというのはそうですが。 CDNでSSR結果をキャッシュした方が圧倒的にコンピューティングリソースもかからないのに、なぜNext.jsが好きな人たちはISRしたがるんだろうね。君たちどうせNode.jsサーバーの監視もメンテも碌にしないじゃんっていうお気持ち - 貧弱モバイル/低速ネットワーク
- 膨大なコンテンツで構成されるページ
が揃ったところで INP に違いが出てくるのかなぁと想像しています（未検証）
@yuta0801_: @takepepe INPの改善であれば、すぐに使えるselective hydrationでnon-blockingになるのである程度改善できそうです （余談ですが、そのスレッドで僕が言ったpartial hydrationはパフォーマンスの話ではなく、RSCによるサーバー側テンプレートというメンタルモデルを意図してました）
@takepepe: @yuta0801_ 余談 -> その通りですね。今までCSRで部分的にやっていた箇所。他にもウォーターフォールが発生するコンポーネント構造（画面構成）で計測しないと、メリットが見えないように思います。 しかも、そのパーシャルをフロントのロジックとは結構分離しないためのテクニックも必要なわけで。
そこまでパフォーマンス的に厳しいアプリをあまり知らないっちゃ知らない。
ただ、ビジネスロジックをサーバーサイドに寄せるという当たり前のことが当たり前に行われる設計にはなるので、そこに関しては評価してるし、みんながnextjs的にそっちに行ってささっとフルスタックフレームワークにならないとダメなのはそうだったりする。 ---
koushisa.icon